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REMARKS 

Claims 1 through 18 are pending in the present application. 
Claims 1 through 17 stand rejected under 35 U.S.C. § 103(a). 
Reconsideration is respectfully requested in view of the following remarks. 



Rejection Under 35 U.S.C. § 103(a) 
Claims 1 through 16 stand rejected under 35 U.S.C. § 103(a) as allegedly 
being rendered obvious over U.S. patent number 7,418,418 (hereinafter "Wizon"), in view of 
U.S. patent number 7,467,108 (hereinafter "Papka"), and further view of U.S. patent 
publication 20020042770 (hereinafter "Slyke"). Applicant respectfiiUy submits that the 
Office cannot meet its legal burden under 35 U.S.C. § 103(a) to establish a prima facie case 
of obviousness of the amended claims based upon the cited references. Reconsideration is 
respectfiiUy requested. 

Amended claim 9 recites: 

A method implemented on a computing system for 
pricing a financial product, comprising: 

transmitting for display a first user interface; 
receiving into the computing system via the first user 
interface data that identify and describe the product, the data 
comprising: contextual data of the product, the contextual data 
indicating market variables involved in product pricing and 
used for selecting a market hypothesis for pricing the product, 
the contextual data comprising at least one valuation currency 
and at least one underlying instmment; and characteristic data 
of the product comprising a plurality of future financial flows 
associated with the product, the plurality of future financial 
flows defined using at least one numerical equation^ 

wherein receiving via the first user interface data 
that identify and describe the product comprises: 

receiving in a first portion of the first user 
interface user inputs specifying a first term 
associated with the product and a first definition for 
the first term comprising a first numeric value; 

receiving in the first portion of the first user 
interface user inputs specifying a second term 
associated with the product and a second definition 
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for the second term comprising a second numeric 
value and a reference to the first term; 

receiving in a second portion of the first user 
interface user inputs specifying a first financial flow 
associated with the product, the first financial flow 
specified with a start date for the first financial flow, 
a frequency of the first financial flow, and a 
description of the flrst flnancial flow defined using a 
numerical equation and at least one of the first term 
and the second term; and 

receiving in the second portion of the first 
user interface user inputs specifying a second 
financial flow associated with the product, the 
second financial flow specifled with a start date for 
the second financial flow, a frequency of the second 
flnancial flow, and a description of the second 
flnancial flow deflned using a numerical equation 
and the flrst financial flow; 
in the computing system generating a planned 
schedule from the received data that identify and describe 
the product, the planned schedule comprising for each of a 
plurality of future dates a flnancial flow associated with the 
product and defined using at least in part one of the first 
financial flow and the second financial flow : 

transmitting for display a second user interface, the 
second user interface comprising a listing of the plurality of 
future dates and for each future date a flnancial flow 
associated with the product and deflned using at least in 
part one of the first financial flow and the second financial 
flow: 

in the system, storing in a first table information 
identifying the plurality of future dates and for each future 
date a financial flow defined using at least in part one of the 
first financial flow and the second financial flow: 

in the computing system interpreting the schedule in 
order to identify product variables for the product on the 
basis of at least one of a first financial flow and a second, 
and for each date of the planned schedule, a function for 
calculating a price associated with the product as a function 
of at least one of the product variables; 

in the system, storing in a second table information 
identifying for each date of the planned schedule, a function 
for calculating a price associated with the product; 

in the system, storing in a third table the identified 
product variables: 
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in the computing system receiving market variables 
associated with the product and generated by a market 
analysis, the market variables identified for each of the 
plurality of dates on the schedule; 

in the system, storing in a fourth table the received 
market values associated with the product: 

in the computing system calculating using the market 
variables, for each of a plurality of market scenarios and 
for each of the plurality of dates on the schedule, product 
variable values; and 

in the computing system calculating a product price as a 
function of the calculated product variable values. 

In order for a set of references to render claim 9 obvious, the references must disclose each 
and every element of the recited claim and disclose arranging the recited elements to form the 
recited combination. See M.P.E.P. § 2143.03 ("[t]o establish prima facie obviousness of a 
claimed invention, all the claim limitations must be taught or suggested by the prior art.") 
Applicant respectfully submits that Wizon and Papka do not disclose or suggest at least the 
above-emphasized claim language and therefore cannot possibly teach the recited 
combination. 

Wizon discloses a computer-based system for pricing fixed income securities. In the 
system disclosed by Wizon, users select a portfolio of fixed income securities from a 
portfolio database and then select a pricing method for pricing one of the fixed income 
securities in the selected portfolio. (Abstract). Wizon discloses calculating the price of the 
selected fixed income security based upon the designated pricing method. (Abstract). 

Thus, in Wizon, a user selects a pricing model for a selected fixed income security 
and the system calculates the price. But in contrast with the claim language, Wizon does not 
disclose: 

wherein receiving via the first user interface data 
that identify and describe the product comprises: 

receiving in a first portion of the first user 
interface user inputs specifying a first term 
associated with the product and a first definition for 
the first term comprising a first numeric value; 

receiving in the first portion of the first user 
interface user inputs specifying a second term 
associated with the product and a second definition 
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for the second term comprising a second numeric 
value and a reference to the first term . 

Wizon discloses a user interface (Figure 2) that allows for viewing existing portfolios and 
adding securities to a portfolio. While the user interface as disclosed by Wizon allows for a 
user to input data about a security, the interface does not accept user inputs that "specify[] a 
first term associated with the product and a first definition for the first term comprising a 
first numeric value." Likewise, the user interface disclosed in Wizon does not accept user 
inputs that "specify[] a second terai associated with the product and a second definition for 
the second term comprising a second numeric value and a reference to the first term ." 
Indeed, the interface disclosed by Wizon does not provide for "specifying a . . . term" at all, 
and further does not provide for "specifying . . a ... definition for the ... term comprising 
a . . . numeric value." Certainly, the user inputs accepted in the user interface as disclosed 
by Wizon does not "specify[] ... a ... definition for the second term comprising a second 
numeric value and a reference to the first term." 

Moreover, the user interface disclosed by Wizon does not provide for: 

receiving in a second portion of the first user 
interface user inputs specifying a first financial flow 
associated with the product, the flrst flnancial flow 
specified with a start date for the first financial flow, 
a frequency of the first financial flow, and a 
description of the first financial flow defined using a 
numerical equation and at least one of the first term 
and the second term ; and 

receiving in the second portion of the first 
user interface user inputs specifying a second 
financial flow associated with the product, the 
second financial flow specified with a start date for 
the second financial flow, a frequency of the second 
financial flow, and a description of the second 
financial flow defined using a numerical equation 
and the first financial flow . 

Wizon discloses a user interface in which a user may enter a "pricing method." (Col. 3, 11. 65- 
66). But receiving a pricing method in a user interface as disclosed by Wizon does not 
provide for "receiving . . . user inputs specifying a first financial flow associated with [a] 
product," and "receiving . . . user inputs specifying a second flnancial flow associated with 
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the product." Indeed, the single pricing method as disclosed by Wizon is not a "user input[] 

specifying a first financial flow" and "user inputs specifying a second financial flow" at all. 

Certainly, the user interface of Wizon does not provide for "receiving . . . user inputs 

specifying a second financial flow associated with the product, the second financial flow 

specified with ... a description of the second financial flow defined using a numerical 

equation and the first financial flow." 

The Office has acknowledged (see Office Action at p. 5) that Wizon does not disclose 

or suggest language similar to the following amended claim language: 

generating a planned schedule from the received 
data that identify and describe the product, the planned 
schedule comprising for each of a plurality of future dates a 
financial flow associated with the product and defined using 
at least in part one of the first financial flow and the second 
financial flow. 

Applicants respectfully submit that Wizon also does not disclose: 

in the system, storing in a first table information 
identifying the plurality of future dates and for each future 
date a financial flow defined using at least in part one of the 
first financial flow and the second financial flow. 

Indeed, Wizon does not even mention a table, and certainly not describe or suggest a table as 

recited in the claim language. 

The Office has also acknowledged (see Office Action at p. 5) that Wizon does not 

disclose or suggest language similar to the following amended claim language: 

in the computing system interpreting the schedule in 
order to identify the product on the basis of at least one of a 
first flnancial flow and a second financial flow, and for each 
date of the planned schedule, a function for calculating a 
price associated with the product as a function of at least 
one of the product variables. 

Applicants respectfully submit that Wizon also does not disclose: 

in the system, storing in a second table information 
identifying for each date of the planned schedule, a function 
for calculating a price associated with the product; [and] 

in the system, storing in a third table the identified 
product variables. 
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Again, Wizon does not even mention a table, and certainly does not disclose a table as recited 

in the claim language. 

Applicants further note that Wizon does not disclose: 

transmitting for display a second user interface, the 
second user interface comprising a listing of the plurality of 
future dates and for each future date a financial flow 
associated with the product and defined using at least in 
part one of the first financial flow and the second financial 
flow . 

The Office has alleged that Wizon at column 1, lines 33-35 and column 3, lines 1-9 is 
relevant. Applicants respectfully disagree. Column 1, lines 33-35 disclose programming a 
processor with a formula. Column 3, lines 1-9 discloses that a pricing system controls a 
graphical user interface. But neither of the referenced sections disclose "a second user 
interface , the second user interface comorisinu a listinu of the Diuraiity of future dates 
and for each future date a financial How associated with the product and defined using 
at least in part the at least one of the first financial flow and the second financial flow ." 
Rather, Wizon discloses a single user interface depicted in Figure 2 of Wizon. The single 
user interface does not "compris|e| a listing of the plurality of future dates and for each 
future date a financial flow associated with the product." Certainly, the single user 
interface disclosed by Wizon does not "compris[e] a listing of the plurality of future dates 
and for each future date a financial flow . . . defined using at least in part one of the first 
financial flow and the second financial flow." Applicants respectfully request that should 
the Office maintain the rejection that it quote the specific language that allegedly 
corresponds to the recited claim language. 

Papka does not address the deficiencies of Wizon. Papka discloses a method of 
creating a price prediction model that forecasts short-term price fluctuations in financial 
instruments by collecting, analyzing and classifying financial news for a financial instrument 
into categories. (Abstract). According to Papka, financial analysts review textual financial 
documents obtained from public interest web sites and classify the documents to be either 
"good news" or "bad news" relative to the expected performance of a financial instrument. 
(Col. 2, 11. 32-45). Distributions of historical price changes for a particular financial 
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instrument are sampled from the data based on the occurrences of the different classifications 

of news. (Col. 2, 11. 32-45) (Col. 3, 11. 60-62). The distributions are used to form a model that 

produces buy, sell, and no-trade signals for the financial instrument. (Col. 2, 11. 32-45) (Col. 

3, In. 60 - Col. 5, In. 35). The model is then used to predict when to buy, sell or not trade the 

stock given the daily occurrences of the underlying company's financial news. (Col. 2, 11. 32- 

45) (Col. 5, 11. 35-55). 

Thus, Papka discloses a method wherein classifications of past news stories are 

correlated with the coiTesponding historical price values for a stock to create a model for 

whether a stock value will fall or rise in response to a particular type of news story. In 

contrast with claim 1, Papka does not disclose or suggest: 

receiving via the first user interface data that 
identify and describe the product comprises: 

receiving in a first portion of the first user 
interface user inputs specifying a first term 
associated with the product and a first definition for 
the first term comprising a first numeric value; 

receiving in the first portion of the first user 
interface user inputs specifying a second term 
associated with the product and a second definition 
for the second term comprising a second numeric 
value and a reference to the first term . 

Papka discloses a user interface (Figure IC) that allows a user to classify whether a news 
article is "good," "bad," or "mixed" from the perspective of the particular stock. The user 
interface of Papka that allows for a user to input data that classifies a news article is not the 
same or similar to a user interface that accepts user inputs that "specify[] a first term 
associated with the product and a first definition for the first term comprising a first 
numeric value." Likewise, the user interface disclosed in Papka for accepting a news 
classification does not accept user inputs that "specify[] a second term associated with the 
product and a second definition for the second term comprising a second numeric value 
and a reference to the first term ." Indeed, the interface disclosed in Papka for accepting a 
news classification does not provide for "specifying a . . . term" at all, and fiirther does not 
provide for "specifying . . a ... definition for the ... term comprising a . . . numeric 
value." Certainly, the user inputs accepted in the user interface as disclosed by Paka do not 
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"specify[] ... a ... definition for the second term comprising a second numeric value and 
a reference to the first term." 

Moreover, the user interface disclosed by Papka does not provide for: 

receiving in a second portion of the first user 
interface user inputs specifying a first financial flow 
associated with the product, the first financial flow 
specified with a start date for the first financial flow, 
a frequency of the first financial flow, and a 
description of the first financial flow defined using a 
numerical equation and at least one of the first term 
and the second term ; and 

receiving in the second portion of the first 
user interface user inputs specifying a second 
financial flow associated with the product, the 
second financial flow specified with a start date for 
the second financial flow, a frequency of the second 
financial flow, and a description of the second 
financial flow defined using a numerical equation 
and the first financial flow . 

The user interface of Papka tiiat allows for a user to input data that classifies a news article is 

not the same or similar to a user interface for "receiving . . . user inputs specifying a first 

financial flow associated with [a] product," and "receiving . . . user inputs specifying a 

second financial flow associated with the product." The classification of a news article as 

disclosed by Paka is not a "user input[] specifying a first financial flow" and "user inputs 

specifying a second financial flow" at all. Certainly, the user interface of Papka does not 

provide for "receiving . . . user inputs specifying a second financial flow associated with the 

product, the second financial flow specified with ... a description of the second financial 

flow defined using a numerical equation and the first financial flow ." 

In further contrast with the claim language, Papka does not disclose or suggest 

language similar to the following amended claim language: 

generating a planned schedule from the received 
data that identify and describe the product, the planned 
schedule comprising for each of a plurality of future dates a 
financial flow associated with the product and defined using 
at least in part one of the first financial flow and the second 
financial flow . 
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Rather, Papka discloses using past new articles to generate a price prediction model. But 
past news articles are not a "planned schedule." Furthermore, past news articles are not "a 
planned schedule from the data that identify and describe the product ." Most certainly, 
a price prediction model determined by a correlation with a news article is not a "planned 
schedule comprising for each of a plurality of future dates a financial flow associated with the 
product and defined using at least in part one of the first financial flow and the second 
financial flow ." Indeed, Papaka does not disclose receiving "[a] first financial flow and [a] 
second financial flow" and therefore cannot possibly disclose a "planned schedule . . . 
defined using ... the first financial flow and the second financial flow." 

The Office cites to column 2, lines 25-46 as allegedly relevant to "future financial 
events [and] generating a planned schedule." Admittedly, and as discussed above, Papka 
discloses that "[t]he model may be used to predict when to buy, sell, or not trade the stock 
given the daily occurrences of the underlying company's financial news." But, the model 
disclosed by Papka does not contain a " planned schedule comprising for each of a 
plurality of future dates a financial fiow associated with the product and defined using 
at least in part one of the first financial fiow and the second financial fiow ." Indeed, 
Papka does not disclose a "schedule" at all and certainly not a "planned schedule comprising 
for each of a plurality of future dates a financial fiow associated with the product." A 
prediction as to whether a stock price will rise or fall as disclosed by Papka, is not a 
" planned schedule comprising for each of a plurality of future dates a financial flow 
associated with the product." Indeed, a prediction that a stock price may rise or fall is not a 
financial flow at all. Certainly, a prediction as to whether a stock price will rise or fall is not 
a "planned schedule comprising for each of a plurality of future dates a financial flow . . . 
defined using at least in part one of the first financial flow and the second financial 
fiow ." 

Papka also does not disclose: 

in the system, storing in a first table information 
identifying the plurality of future dates and for each future 
date a financial flow defined using at least in part one of the 
first financial flow and the second financial flow. 
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Indeed, Papka does not even mention a table, and certainly not describe or suggest a table as 
recited in the claim language. 

Papka also does not disclose "interpreting the schedule in order to identify 
product variables for the product on the basis of at least one of the first financial flow 
and the second financial flow, and for each date of the planned schedule, a function for 
calculating a price associated with the product as a function of at least one of the 
product variables ." As noted above, Papka does not disclose "generating a planned 
schedule." Therefore, Papka cannot possibly disclose "interpreting the schedule." If the 
Office should maintain the rejection, the undersigned respectfully requests that the Office 
identify the particular "product variables" that are "identify[ied]" and quote the specific 
language that allegedly discloses "identify [ing] product variables for the product on the basis 
of at lease one of the first financial flow and the second flnancial flow." 

Applicants respectfully submit that Papka also does not disclose: 

in the system, storing in a second table information 
identifying for each date of the planned schedule, a function 
for calculating a price associated with the product; [and] 

in the system, storing in a third table the identified 
product variables. 

Again, Papka does not even mention a table, and certainly does not disclose a table as recited 
in the claim language. 

The Office cites to Slyke as allegedly disclosing "future financial flows defined using 
at least one numerical equation." In fact, the referenced paragraph of Slyke (paragraph 
[0109]) discloses estimating cost and cash flows. But Slyke does not disclose, and the Office 
does not allege, the remaining claim language as discussed above. 

Therefore, because neither Wizon, Papka, not Slyke disclose or suggest at least the 
above-emphasized claim language, it cannot possibly disclose or suggest the combination 
recited in claim 9. Accordingly claim 9 and the claims depending therefrom are not rendered 
obvious. Although the language of claims 1 and 17 is different from that of claim 9, for 
reasons similar to those discussed above, claims 1 and 17 are not rendered obvious. 

Reconsideration and withdrawal of the rejection under 35 U.S.C. § 103(a) is 
respectfully requested. 
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Conclusion 

Applicant respectfully submits that the present application is in condition for 
allowance. Early notification to this effect is requested. 

If Examiner Niquette should have any questions regarding this response, the 
Examiner is invited to contact the undersigned attorney at (215) 568-3100. 



Date: August 13, 2010 /John F, Mrfilynn/ 



John E. McGlynn 
Registration No. 42,8 



Woodcock Washburn LLP 
Cira Centre 

2929 Aix;h Street, 12th Floor 
Philadelphia, PA 19104-2891 
Telephone: (215) 568-3100 
Facsimile: (215) 568-3439 
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